Re: [gentoo-user] [OT] dmg2img hfs+ disk image
On Saturday, 23 February 2019 00:57:45 GMT Andrew Udvare wrote: > > On Feb 22, 2019, at 19:00, Mick wrote: > > > > Hi All, > > > > A bit off topic, but given I'm trying this on a gentoo system and the high > > cumulative knowledge of contributors to this M/L, I thought I might as > > well > > ask here. I'm trying to access the various partitions within a .dmg > > archive, > This way using the kernel HFS+ driver: > > https://github.com/nickl-/xchain-ios#prepare-your-prefix-no-mac > > This way without the driver: > > https://github.com/Tatsh/xchain#prepare-your-prefix-no-mac WOW! I should have posted earlier. ;-) Thanks Andrew. I tried with the kernel driver, since I have it built in the kernel and also have sys-fs/diskdev_cmds and sys-fs/hfsplusutils already installed, but don't have java available. It won't work: = # 7z x BaseSystem.dmg 7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,64 bits,8 CPUs Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz (106E5),ASM) Scanning the drive for archives: 1 file, 482126050 bytes (460 MiB) Extracting archive: BaseSystem.dmg -- Path = BaseSystem.dmg Type = Dmg Physical Size = 482126050 Method = Copy Zero2 ZLIB CRC Blocks = 590 Path = 4.hfs Size = 2013085696 Packed Size = 482080513 Comment = disk image (Apple_HFS : 4) Method = Copy Zero2 ZLIB CRC -- Path = 4.hfs Type = HFS Physical Size = 2013085696 Method = HFS+ Cluster Size = 4096 Free Space = 740196352 Created = 2018-10-24 02:10:14 Modified = 2018-10-24 09:23:00 Everything is Ok Folders: 10639 Files: 39974 Size: 1121934759 Compressed: 482126050 # ls -la total 470844 drwxr-xr-x 3 michael michael 4096 Feb 23 08:43 . drwxr-xr-x 7 michael michael 4096 Feb 22 19:22 .. -rw-r--r-- 1 michael michael 482126050 Feb 22 19:25 BaseSystem.dmg drwx-- 16 rootroot 4096 Oct 24 10:14 'OS X Base System' # mount -t hfsplus -o loop 4.hfs /media/dmg mount: /media/dmg: failed to setup loop device for 4.hfs. It seems the 4.hfs image is not extracted as a separate component? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] [OT] dmg2img hfs+ disk image
On 23/02/2019 04:30, Mick wrote: > # mount -t hfsplus -o loop 4.hfs /media/dmg > mount: /media/dmg: failed to setup loop device for 4.hfs. What does dmesg show? It should give more detail about the problem. Also try with `mount -v`. Normally 7z gets into the partition and extracts the files within, but only if the 'Method' is supported, like 'Zero0 Copy Zero2 ZLIB CRC'. Yours is 'Copy Zero2 ZLIB CRC'. Also you might want to try https://github.com/darlinghq/darling-dmg with the DMG file itself. This is far more active than the kernel module.
Re: [gentoo-user] [OT] dmg2img hfs+ disk image
On Saturday, 23 February 2019 10:32:20 GMT Andrew Udvare wrote: > On 23/02/2019 04:30, Mick wrote: > > # mount -t hfsplus -o loop 4.hfs /media/dmg > > mount: /media/dmg: failed to setup loop device for 4.hfs. > > What does dmesg show? It should give more detail about the problem. Also > try with `mount -v`. I think the above message indicates there is no 4.hfs to be mounted. No messages are reported in dmesg, or syslog. > Normally 7z gets into the partition and extracts the files within, but > only if the 'Method' is supported, like 'Zero0 Copy Zero2 ZLIB CRC'. > Yours is 'Copy Zero2 ZLIB CRC'. Should I be using a different incantation with 7z to apply the correct method? I've tried various things, but I can't come up with the correct syntax. > Also you might want to try https://github.com/darlinghq/darling-dmg with > the DMG file itself. This is far more active than the kernel module. Thanks, I'll take a look at this too. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] PSA: openrc-0.41 system borkage & ro root fs on next boot
Last night openrc was updated to ~0.41, supposedly fixing [1]. Unfortunately it seems it had the opposite effect and made things worse compared to the previous 0.42.3 - the deptree is broken, rc-status remains confused and a reboot results in a read-only root fs because (I think) the runlevels are all mixed up, esp. /etc/runlevels/boot. Restoring /etc/runlevels from backup & downgrade to 0.40.3 fixed it. If someone can reproduce this in a VM (I cannot do so right now) please file a bug with more information. hth, Holger [1] https://bugs.gentoo.org/659906
Re: [gentoo-user] PSA: openrc-0.41 system borkage & ro root fs on next boot
Holger Hoffstätte schrieb am 23.02.19 um 15:15: > > Last night openrc was updated to ~0.41, supposedly fixing [1]. > > Unfortunately it seems it had the opposite effect and made things worse > compared to the previous 0.42.3 - the deptree is broken, rc-status > remains confused and a reboot results in a read-only root fs because > (I think) the runlevels are all mixed up, esp. /etc/runlevels/boot. > > Restoring /etc/runlevels from backup & downgrade to 0.40.3 fixed it. > > If someone can reproduce this in a VM (I cannot do so right now) please > file a bug with more information. > > hth, > Holger > > [1] https://bugs.gentoo.org/659906 > > > Same here! However I am still on sys-apps/openrc-0.38.3-r1. I think the culprit is sys-fs/udev-init-scripts-33 which got an upgrade from version 32 on the day before this started happening! -- Regards Daniel
Re: [gentoo-user] PSA: openrc-0.41 system borkage & ro root fs on next boot
Daniel Pielmeier schrieb am 23.02.19 um 16:25: > Holger Hoffstätte schrieb am 23.02.19 um 15:15: >> >> Last night openrc was updated to ~0.41, supposedly fixing [1]. >> >> Unfortunately it seems it had the opposite effect and made things worse >> compared to the previous 0.42.3 - the deptree is broken, rc-status >> remains confused and a reboot results in a read-only root fs because >> (I think) the runlevels are all mixed up, esp. /etc/runlevels/boot. >> >> Restoring /etc/runlevels from backup & downgrade to 0.40.3 fixed it. >> >> If someone can reproduce this in a VM (I cannot do so right now) please >> file a bug with more information. >> >> hth, >> Holger >> >> [1] https://bugs.gentoo.org/659906 >> >> >> > > Same here! However I am still on sys-apps/openrc-0.38.3-r1. I think the > culprit is sys-fs/udev-init-scripts-33 which got an upgrade from version > 32 on the day before this started happening! > What's to add is that restarting from the semi booted state always resulted in the same partial boot with the rootfs mounted read-only. After fixing this by manually starting all services everything was fine after the next boot. Today when booting again the same happened. I am writing this now from the manually started system. I will try restarting over and check if I can reproduce this issue reliable. -- Regards Daniel
Re: [gentoo-user] PSA: openrc-0.41 system borkage & ro root fs on next boot
Daniel Pielmeier schrieb am 23.02.19 um 16:37: > Daniel Pielmeier schrieb am 23.02.19 um 16:25: >> Holger Hoffstätte schrieb am 23.02.19 um 15:15: >>> >>> Last night openrc was updated to ~0.41, supposedly fixing [1]. >>> >>> Unfortunately it seems it had the opposite effect and made things worse >>> compared to the previous 0.42.3 - the deptree is broken, rc-status >>> remains confused and a reboot results in a read-only root fs because >>> (I think) the runlevels are all mixed up, esp. /etc/runlevels/boot. >>> >>> Restoring /etc/runlevels from backup & downgrade to 0.40.3 fixed it. >>> >>> If someone can reproduce this in a VM (I cannot do so right now) please >>> file a bug with more information. >>> >>> hth, >>> Holger >>> >>> [1] https://bugs.gentoo.org/659906 >>> >>> >>> >> >> Same here! However I am still on sys-apps/openrc-0.38.3-r1. I think the >> culprit is sys-fs/udev-init-scripts-33 which got an upgrade from version >> 32 on the day before this started happening! >> > > What's to add is that restarting from the semi booted state always > resulted in the same partial boot with the rootfs mounted read-only. > After fixing this by manually starting all services everything was fine > after the next boot. Today when booting again the same happened. I am > writing this now from the manually started system. I will try restarting > over and check if I can reproduce this issue reliable. > Rebooting a few times always resulted in a failed boot! Maybe the other time I was just lucky. Downgrading to sys-fs/udev-init-scripts-32 seems to fix the issue. I opened bug 678638 [1] about this issue. [1] https://bugs.gentoo.org/678638 -- Regards Daniel
Re: [gentoo-user] fresh gentoo installation reboot fs read only (SOLVED)
Dear Davyd, Thanks again. Have a nice weekend. On 22.02.19 19:13, Davyd McColl wrote: On 2019/02/22 19:52:57, Tamer Higazi wrote: Hi David, you were absolutely RIGHT. I knew only from the past the Gentoo Installations, where the UUID was not necessary. I executed "blkid", took the UUID for the desired to mounted device, wrote it in the fstab file before I reexecuted grub-mkconfig Thanks for your edvises in the chat and the mailinglist **you're welcome -- this list has been well helpful to me (and I've learned a lot by following it). I'm quite a fan of the Gentoo userbase -- so helpful! Must reciprocate when possible (: best, Tamer On 19.02.19 05:13, Davyd McColl wrote: > > > On February 19, 2019 00:27:34 Tamer Higazi wrote: > >> Hi people, >> I made a fresh systemd installation based and generated the kernel >> with genkernel. >> I am not capable to login after reboot. It is a EFI installation based >> on systemd >> >> I saw in the internet similiar posts, and I am stuck and not getting >> it solved somehow to login with write access. >> >> Has anybody of you an idea what I made wrong? >> >> I would kindly thank the gentoo community supporting me solving this >> issue. >> >> grub options: >> https://pastebin.com/raw/hEaP5Mv0 >> >> genkernel linux config >> https://pastebin.com/raw/7CSYLfrS >> >> gentoo /etc/fstab: >> https://pastebin.com/raw/zL19iQiZ > Just curious - how does mount know how to identify your block devices? > This fstab has no device identifier at the start of each line (eg > /dev/sda7, as mentioned in a comment above the line for root, or, > better, UUID= identifiers, as suggested in the higher up commentary). > I don't run systemd (so I'm not sure if it does something magick > here?), but I wouldn't expect this fstab to work on any of the systems > I've used. >> >> grub.cfg file: >> https://pastebin.com/7KxJCp9F >> >> >> Thank you. >> >> >> >> >> best, Tamer >> > > >
